这是一个创建于 4365 天前的主题，其中的信息可能已经有所发展或是发生改变。
刚刚进入大三的学生，最近和同学开发一个网站，也算是cms吧 人一多遇到的全是坎坷。到底是先分工再写，还是如何。接口自始至终都没有完整的定义过，编写边改 哪怕是写的时候 也没有接口说明作为参照。在我看来能开发出这套系统确实令人惊叹。
后台写完了等前端，等了一段时间等到前端写完了，发现双方留的接口完全对不上，然后有一方选择改动。陷入了零和博弈，简单的说，前端和后台分为两组，必然有一方要改动，总有一方可以快乐的不改，但是这种快乐必然是建立在另一组的痛苦之上。写的无比艰辛，甚至让我怀疑我是否真的会编程。明明知道自己能力有限，做常常纠结与一个类怎么能写的更好，在未来可能会更具有扩展性，结果一个类一改再改。
在写这套系统的时候，算法和数据结构，反而成为了次要的东西，软件一开始的接口的说明， 如何设计这套系统耦合， 单独的模块怎么算测试通过，两个模块怎么耦合， 更多的是属于软件工程和设计模式的东西。
也算是边学边做，有过django的基础，边学pyramid边用， 顺便又熟悉了不少应用层上的东西。算是了解了登录系统的原理，然后又加了一层来让android不持有cookie也能通过同一套系统的验证。然后又设计了一套通知系统，sns的那种，不过估计只是勉强能用，一旦遇到海量数据就必崩无疑。
一套系统是不是开始的设计主要是看架构，然后才考虑性能呢。总觉得一开始过分的关注细枝，拖慢了开发进程。
也算是第一次有了多人使用git的经验。
整个开发略感难受，但是也学到了很多，
更重要的，是发现要学习的还有很多
blog：
http://www.darkof.com/?p=77
后台写完了等前端，等了一段时间等到前端写完了，发现双方留的接口完全对不上，然后有一方选择改动。陷入了零和博弈，简单的说，前端和后台分为两组，必然有一方要改动，总有一方可以快乐的不改，但是这种快乐必然是建立在另一组的痛苦之上。写的无比艰辛，甚至让我怀疑我是否真的会编程。明明知道自己能力有限，做常常纠结与一个类怎么能写的更好，在未来可能会更具有扩展性，结果一个类一改再改。
在写这套系统的时候，算法和数据结构，反而成为了次要的东西，软件一开始的接口的说明， 如何设计这套系统耦合， 单独的模块怎么算测试通过，两个模块怎么耦合， 更多的是属于软件工程和设计模式的东西。
也算是边学边做，有过django的基础，边学pyramid边用， 顺便又熟悉了不少应用层上的东西。算是了解了登录系统的原理，然后又加了一层来让android不持有cookie也能通过同一套系统的验证。然后又设计了一套通知系统，sns的那种，不过估计只是勉强能用，一旦遇到海量数据就必崩无疑。
一套系统是不是开始的设计主要是看架构，然后才考虑性能呢。总觉得一开始过分的关注细枝，拖慢了开发进程。
也算是第一次有了多人使用git的经验。
整个开发略感难受，但是也学到了很多，
更重要的，是发现要学习的还有很多
blog：
http://www.darkof.com/?p=77
 |
1
raptor 2012-12-09 22:47:31 +08:00
自已写和团队写是两回事，一个项目居然没有人做协调工作真是……
|
 |
2
picasso250 2012-12-09 22:55:47 +08:00  2
当年，总以为把厚厚的《数据结构》和《算法》读透了就无敌和牛逼了。后来写项目的时候才发现，数据结构和算法基本用不上，给变量命名才是最难的事情。
|
 |
3
adamwen OP |
 |
4
yuelang85 2012-12-09 23:35:37 +08:00 2
简单说说我最近做的一个小工具的经历，不过是自己做的。
我是目标驱动。 首先明确要做一个啥玩意儿。然后大致的分析下需要那几个大功能，比如登陆（包括session管理），文章，留言，搜索，rss支持啥啥啥的。 然后呢，画几个主要页面。比如首页，单独文章页面。 以blog为例，如果你和你的同伙把单独文章页面详细画出来了，那么这个blog系统基本可以定型了。由于有了详细页面，前端也知道了要展示哪些数据，后端也就知道了前端需要什么数据，剩下的就是前端铺页面，后端组织数据就是了。 一开始先把整套程序简单化，只做主要的部分（我做的小工具一开始连登陆验证都没有），然后随时看效果（前后端一起），一点一点复杂自己的程序（迭代开发）。 一开始不需要想架构。当然我说的是没经验的人，你这时候没有任何实践，有没有任何用户（或者用户很少），不如先把东西做出来，以后根据实际情况改。 不用怕重构（不管是代码还是架构），只要前端页面不变，你最终给的数据就不变，那么只要保证这一层，后端不管是代码还是架构，随便折腾。 有了一些编码经验以后，就可以在项目开始时考虑代码结构问题了。架构问题，没有接触过生产环境的话，看啥文章都是纸上善谈兵。 关于数据结构和算法，我是宏观看待之：数据结构就是数据的储存和管理，那么不仅仅是链表，树的问题，还有储存到哪里，如何分配问题。算法不仅仅是排序啥的，还应该有些架构方面，比如，如何负载一类的。我们常说的算法与数据结构，看似都是微观问题，如果活学活用，放开眼光，会发现真的就应了那个公式：算法＋数据结构＝程序。其实我更喜欢这么看：程序就是 f(x)，其中f是算法，x是数据。 胡扯，欢迎批评。 |
 |
5
AntiGameZ 2012-12-10 01:57:26 +08:00 3
对于生手来说，什么架构啊，谈架构等于玩死自己。
大家都没经验，自然也没有最佳实践可言，硬套 OOP，设计模式，活出不来还会给团队带来挫败感，最终严重拖慢进度。 自己也是这么过来的，记得自己真正意义上的第一个团队项目，是4个人，都是学生，1个美工，3个程序员，没有前端并且在程序刚开始做的时候，只有我略懂 HTML/CSS/JS。 很巧，这个项目也是个CSS，并且，因为某些原因，必须从头写起，不能用现成的代码改。项目期只有1个月，大家一周能聚在一起的时间，只有周末。一周下来，真正开发的时间，摊到每个程序员头上，最多10个小时。 美工很早就把设计图出来了，没人懂切图，于是纠结在切图究竟是美工学好呢，还是程序员学好呢。最终是我拉了一个“高手”，把图切了，按照切的图，我带着另一个程序员，硬着头皮把前端做完了。此时，逻辑代码数量为0。时间已经是第二周中了。 美工看没什么事情，就一个人去1000多公里外，见从来没见过的网友妹子了，据说，要去一周。 数据库的表，在项目开始之前，我就建好了，此时翻出来对着前端功能看，很多不能自圆其说。自己觉得应该讨论一下，于是第二周剩下的时间，就花在表结构上。事实证明，“更加完善”的表结构，引入了很多没有必要的“扩展性”。 第三周中，终于进入代码编写阶段。项目用的ASP.NET，当时版本2.0，所谓的架构不过是一个微软MVP写的一套三层架构的系列文档，纯英文。后来回想，这个文档很有Magic Demo的感觉——告诉你，ASP.NET+ADO.NET是个多么帅的框架，OOP，设计模式在双A框架里，是多么容易融合。 真做起来就完全不一样了，首先是怎么分工，3个程序员，我和A略强，B略弱，任务平均分给3个人自己回去写。到了第三周周末的时候合代码。 问题就来了。 虽然说事前约定好了代码规范，但是花括号到底是跟在签名后面呢还是重起一行没说过，a, b, c这种变量名虽然说了不要用，但是1个函数下来，到处都是ret strA, intB也不行啊。数据库的外键关系改了又改总发现还是不能随心所欲的删改数据，干脆就不要用外键了吧。又总觉得几个表功能差不多，是不是要继承一下？学习了什么叫做单表继承，多表继承。拿回来发现ADO.NET没法这么玩。Google了一圈，发现ADO.NET其实是可以这么玩的，只不过你要实现N个接口，M个抽象类，还得在程序初始化的时候做1，2，3，4，5件事情。三层架构，处在中间的业务逻辑层，似乎完全没用处。 所有的所有，折腾到交工的1个月的最后一天，手写代码虽有近3000行，网站可用性依然是0。 最惨的是，我自己发现，“标准” HTML/CSS/JS，套到ASP.NET上，几乎是没法用的，因为奇葩的ASP.NET，居然会在运行时，动态改变前端元素的ID。如果要用微软推荐的套用设计的方案，又要新学一大堆东西。 在第六周快结束的时候，3个程序员都泄气了，没人觉得再给1个月的时间，这网站可以完工。美工同学见光死回来了1个多月没见人，我们也不好意思去找他。很多前端要改的图，就让程序不是很强的程序员C代劳了。我美其名曰研究架构，没有1秒钟不想把整个程序推翻了重新来一遍。B也迷茫了，虽然陆续完成了用户、权限、发文的功能，但是怎么都觉得不对味道。 然后就没有然后了，一共花了2个月时间的代码，最终烂在我电脑里一直到现在。项目最后用Wordpress交工，当时说坚决不能用现成代码的甲方，什么也没说。 -------------------------------------------------------------------------------------------------------------------------- 直到今天，如果让我问自己怎么做程序架构设计，我想只有1个答案，在你完成了解自己要做什么，对要做的东西，至少每个部分实现过2次以上，再去谈架构，谈优化。未知项目，探索性要求高的项目，只谈实现。 |
 |
6
meta 2012-12-10 15:16:49 +08:00
哈哈，一拥而上，看起来有点山寨。
|
 |
7
yegle 2012-12-10 15:38:20 +08:00 1
曾经要开发一个资产管理平台。机架服务器、刀片服务器、虚拟机，还有树状的位置，以及用途上的逻辑分层…
我是不会告诉你我先是野心勃勃准备用mongodb的schemaless特性做同一张表里的多态，后来投降用mysql老老实实做多表继承，最后废掉外键代码上做关联…可算是做出来了… 从那以后就知道，为了未来的可扩展做提前优化简直就是坑爹…数据库表结构、类的设计这些只能慢慢改，步子大了扯着蛋不好… |
 |
8
happypy1 2012-12-10 16:52:18 +08:00
其实我觉得文档很重要。
|
 |
10
clino 2012-12-10 20:56:32 +08:00
@yegle "一个资产管理平台。机架服务器、刀片服务器、虚拟机，还有树状的位置，以及用途上的逻辑分层"
这个不是 ldap 可以干滴事吗? |
 |
11
alexrezit 2012-12-10 21:20:14 +08:00
国内的大学乐呵乐呵就行了, 没必要认真.
|
|
12
adamwen OP |
|
13
AntiGameZ 2012-12-10 23:07:31 +08:00 1
@adamwen 文档也是在真正了解自己要做什么的基础上才能够产生。不然那叫学习笔记。
学生时代确实遇到过好Partner，半个ABC，两个愣头青接到项目，要搞一个环境项目中的RRDTool。接手的时候完全不知道怎么做，看了cacti的代码直接丧失信心。只不过老美钱多人傻，终究不忍放弃。我们两个人一起在Skype上大概圈好了需要学习的技术范围（这时候已经有点经验，技术和资料都知道求精求实用），分好了工。白天时候各自看自己需要管的部分，晚上回去再花差不多时间说给对方听。竟然一周不到的时间，把基本技术搞懂，而副产物是一大堆word，手绘图例的电子档。 之后，我很邪恶的拉了一个学弟，把我们凌乱不堪的“学习笔记”交给他“整理成文档”，这小子也很神奇，用了两天时间居然就搞好了，加上PHP基础比我好，3个人居然用了整整4周的时间，把这玩意给搞定。产品虽不漂亮，但是功能完整，文档也由ABC翻译成了英文，还另外找了美工设计好手册。最后每个人差不多拿了5000刀走人。 只可惜，这么畅快的合作，仅此一次，发生在即将毕业的寒假，至今也再没有重现过了。 |
|
15
yegle 2012-12-11 01:50:32 +08:00
|
|
18
clino 2012-12-11 09:55:30 +08:00
@yegle 我最近刚在折腾 ldap,这东西本来就是用树状形式来管理一个组织内的人员/群组/资产等等这方面用途的,只是有可能适合你之前说的这种需要,但不能当成一般说的数据库来用,如果对于人员/资产有很多附加信息可能要用结合数据库来使用
|
 |
19
quake0day 2012-12-11 13:10:49 +08:00
做项目不要一开始老想着优化，可扩展性，特别是没有经验的时候。先实现出来，再不断重构才是正路。
|
 |
20
kaifengjin 2012-12-12 23:39:33 +08:00
@picasso250 问题是不看算法和数据结构，找不到工作。。。
|
 |
21
iwege 2012-12-13 07:28:03 +08:00
@yegle 顶一个“ 步子大了扯着蛋不好…”
有关语法风格：如果不是一开始大家都自己已经习惯的语法风格，在开发的时候很难注意到这个，我的做法就是先能跑，然后大家一步步的重构，必要的时候语法风格这种东西直接丢给工具做格式化。 有关海量数据：当年做东西最烦躁的就是想“如果海量数据这个撑不住”，最后老板说了一句：我们运行了几年论坛数据都还没上海量，你刚出来的程序要达到海量很难，还是先出东西好吧。 |
 |
22
firsthym 2012-12-13 11:00:35 +08:00
这就是软件学习从入门到精通的过程，所有高手都是这样过来的，楼主不必自惭形秽。
软件编程是我大学毕业以后工作中自学的，一年的时间恶补计算机本科4年的教程，之后边学变做，开发过一两个项目之后就有经验了。 协调，是在软件工程中一个重要的角色。对于两人小团队，必须先沟通好接口，一周7天，我宁可用5天确定接口，也不想后来重构。 |
Select Language